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AstroMail objectives 


AstroMail was proposed as a suite of user services designed to facilitate and enhance the value of 
electronic communication among members of the Astronomy, AstroPhysics, and Space Science 
research communities. This system was to be based on SolarMail - an existing mad service widely 
used by the Solar Physics research community for the last six years. The proposal descnbed various 
enhancements to SolarMail and outlined the issues that needed to be tackled before budding a 
prototype for AstroMail. 

The various ideas and modifications described in the proposal centered around two core issues. The 
first issue was one of storing information in an organized maimer so that the system was more 
reliable and robust as compared to its predecessor. The second issue was that of managing the 
stored information so as to ease the burden on individuals administering the system. By providing 
a structural framework which dealt with these core issues in an effective manner; it was reasoned 
that the provision of user services would be easier. 

The following services were considered essential to the AstroMail system. 


• Simple syntax emad forwarding . _ , 

The objective was to provide for a uniform syntax for mail addresses that users would in 
convenient to apply in a variety of settings. Such an address form would help in the 
transparent handling of foreign systems and provide support for forwarding and replying. 
Though not quite intended, it was hoped that this would provide the basis for a natur 
evolution to ISO standards in the future. 


• Mail exploders . ... . , , 

The objective was to provide for the dissemination of information to a pre-specitieo list ot 

users. This could therefore be used to help in the distribution of newsletters, bulletins and 
alerts. Support was to be provided for multiple lists, on both a short-term and a long-term 
basis. The control over the membership was to be delegated to group leaders and project 

managers. 

• Directory Information Management 

In addition to the message handling component, AstroMail was to provide for a Directory 
component. This Directory was to be a repository of information about users, projects, and 
correspondence. Individual users were to have the ability to manage personal information 
on their own. Further, they were to have the ability to screen the information that they 
would like to be made available to others. 

• Bulletin Board Services 

In addition to offering active correspondence to the users, AstroMail was supposed to offer 
passive correspondence in the form of bulletin boards. Besides providing for a record of 
activity, it was hoped that it would provide a forum for discussion of ideas and scientific 

thought. 



Tackling the core issues 


Before going on to the issue of storing the information, it was necessary to identify the various 
kinds of information that needed to be stored. We identified the following categones of 
information that needed storage. 


A list of attributes were assigned to each user in the system. The attribute values were to be 
provided by the user, who also had control over how the information would be used. This 
list of attributes is listed in the appendices. 


• Group information , , . ,, 

Each group had an administrator, who had control over the membership and 

information maintained by the group. A group could have sub-groups, each with its own 

administrator. A list of group attributes are listed in the appendices. 


• Logging information , 

For purposes of administration, separate from user and group logs, it was found necessary 

to record exceptional events. A list of relevant attributes are listed in the appendices. 


Given the above information that needed storage, the options regarding storage were examined. 
Each of these options led to differing structures for the system; each of which were evaluated. 


There were three approaches that were considered : 

1) Indexed Storage scheme 

This scheme was developed by Rick Bogart, and was based on storing information 
in the form of records that could be identified uniquely by an index. Such a scheme 
required developing software and routines which would manage the information on 

their own. 

2) Database Storage schemes 

This scheme was initially based on storing the information in a commercial 
database, and using queries to retrieve information as necessary. Such a framework 
would enable rapid access to complex information. 


3) Directory Tree Storage 

This scheme organized all information on a tree structure. The primary advantage 
of this scheme would be the ability to distribute the information over multiple 
machines. Consequently, delegation of responsibility for maintenance would be a 
feasibility. Further, evolution to ISO standards would be considerably easier in the 
future. 



• Modifications to the Information Management scheme 

There were three different approaches that were considered. 

1) Email based schemes . 

This alternative was developed around the idea of using electronic mail for all 
information management. An automatic email processor was partially developed to 
aid in deciphering user requests and information that the user would provide. This 
option would have led to inflexibility in the use of email formats. The only potential 
advantage to such a scheme would be the benefit of the medium of electronic mail 
as the least co mm on denominator. 

2) Guest shell scheme 

A guest shell was developed by Brian Frasca to enable users to modify and access 
information uniformly. This shell could be used by any registered user who could 
avail of "telnef'or "rlogin" facilities. The shell was entirely menu-driven, and could 
provide extensive help facilities to new users and had browsing capabilities. This 
shell could provide the basis for more sophisticated interfaces that could be 
developed later on. 

3) Directory user scheme 

Given previous Directory based schemes, software was available for modification 
so as to custo mize handling of the information. Besides providing X-based 
interfaces and window displays, this scheme also supported simple line interfaces. 
The primary advantage of this scheme was the manner in which information could 
be accessed in a transparent manner from various machines on the network. Further, 
elaborate schemes were available that provided for access control lists, and 
different views of the same data. 


Building the proposed services 

During the course of the project, multiple approaches to achieving objectives were implemented. 
The aims of mail forwarding and mail exploding both depend upon the manner in which the 
address are managed. Hence, it is essential that a solid framework be established for a robust and 
efficient address management scheme. 

Address management was previously done by maintaining an ASCII file contai nin g the SolarMail 
name, and the real address to which mail should be forwarded. This file was read by the mail 
transport agent, namely "sendmail" and then converted into a random access database of aliases. 
Thus, mail explosion and mail forwarding were treated uniformly as a method of recursively 
transforming a single name into a list of real addresses. Sendmail would then do the appropriate 
mailing to the addresses in the so formed list. 



• Modifications to the address management scheme 

There were three different approaches that were implemented. 

1) Local Mail Handling. 

A local mailer, "lxmail" was developed by Scott Rogers. This software, as we 
understand it, provided for a special address syntax which facilitated identification 
and therefore, special mail h andlin g by "lxmail". On identification, the mailer 
would ex amin e a particular database created from a flat file -maintained by the 
group manager/postmaster- and then perform appropriate mapping. After the 
mapping stage, the mail along with the recipient addresses and other relevant 
information would be handed over to the mail transport agent. 

2) Central Mail Handling. 

This approach used a slightly different mail transport agent i.e., Sendmail, 
reinforced with the IDA kit. The idea was to have all mail directed to users or aliases 
in a cer tain domain, say "science.nasa.gov" to be handled by a central machine. This 
machine would run the version of the mail transport agent, as developed at Stanford 
and would examine all envelope addresses. Based on the envelope address and a 
local database of address mappings, this central mailing agent would forward the 
mail to other machines which would then handle the actual mailing. It appears that 
such a scheme is supportive of the "distribution" paradigm underlying the initial 
proposal. 

3) Directory Based Handling. 

This approach relied on utilizing an X.500 based mail transport agent. The basic 
difference between this method and the previous methods is the manner in which 
address mapping is done. In the above methods, such mapping is done by a lookup 
into a table that is m aintain ed at the local machine by the mail transport agent. In 
this scheme, the mailing agent instead of doing the lookup on its own, performs a 
query to a Directory Server Agent (DSA). This DSA then acts upon the query to 
determine what the recipient address ought to be. It is not necessary that the 
Directory be located on the same machine. Further, it may even be spread over a 
number of machines. On receiving the actual address from the DSA, the mail 
transport agent then rewrites the initial address, and performs mail transfer. 

Directory Information Management was intended to reduce the load on the system manager, so that 
users could main tain their personal information in a convenient manner -on their own. It was upto 
the group manager/postmaster to decide whom to include in the mailings to the group. The basis 
of any directory is its content, its storage and the mechanism of its access. It was therefore, essential 
to re-examine and perhaps improve on the SolarMail scheme. 



Future Development 


The aims of the initial proposal are best achieved through utilizing a Directory structure. Besides 
providing for distribution of data, the elaborate security mechanisms offer a robust and reliable 

framework. 



Appendix 1 


Directory Information Tree : 
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Appendix 2 


Information in the DIT : 


We mainly use the following base object classes. 

This is the "root" object class. All other object classes except the 
"alias" object class form subclasses of "top . 

This is a special object class to indicate that the entry is a 
pointer to some real object. 


The following are the object classes being used 

* person 

SUBCLASS OF top 
MUST CONTAIN { 

commonName , 
surname ) 

MAY CONTAIN { 

personAttr ibut eSet , 
telecommunicat ionAttr ibut eSet , 
postal At tr ibuteSet } 

* organization 

SUBCLASS OF top 
MUST CONTAIN { 

organ i zat ionName } 

MAY CONTAIN { 

organizationalAttr ibuteSet) 

* organizat ionalUnit 

SUBCLASS OF top 
MUST CONTAIN { 

organ i zat ionalUni tName } 

MAY CONTAIN { 

organ i zat ional At tribute Set ) 


* mhsDistribut ionList 
SUBCLASS OF top 
MUST CONTAIN { 

commonName , 

mhsDl Submit Permissions , 
mhsOrAddresses) 

MAY CONTAIN { 

description, 

organization, 

organizat ionalUni tName , 

owner, 

mhsDeliverableContentTypes , 
mbsDlMembers , 



mhsPreferredDeliveryMethods) 

* appl icat ionEnt ity 

SUBCLASS OF top 
MUST CONTAIN { 

comraonName , 
presentat icnAddress) 

MAY CONTAIN { 

description, 
localeAttr ibuteSet , 
crganizat ionName , 
organ i zat ionalUnitN&me , 
support edAppl icat ionCont ext } 

* dsa 

SUBCLASS OF appl icat ionEnt ity 
MAY CONTAIN { 

knowledge In format ion) 

* mhsMes sageS tore 

SUBCLASS OF appl icat ionEnt ity 
MAY CONTAIN { 

description, 

owner, 

mhsSupportedOpt ionalAtt r ibut es , 

mhs Support edAutomat ic Act ions , 
mhsSupportedContentTypes ) 

* mhsMe ssageTr an s fer Agent 

SUBCLASS OF appl icat ionEnt ity 
MAY CONTAIN { 

description, 

owner) 

We thus have the following heirarchy of object classes. 

-alias 

-top 

-person 
- organ i zat ion 

-organizat ionalUnitName 
-mhsDistributionList 
-appl icat ionEnt ity 

-dsa 

-mhsMes sageS tore 

-mhsMe ssageTran sport Agent 



Appendix 3 


Object Class Definitions 


# format 

# hiearchy: must :top may 

# name: oia * 

# 

# Set definitions: 

telecommunicat ionAttr ibuteSet = f acs imi leNumber , \ 

telephoneNumber , telexNumber, \ 
pref err eaDe live ryMet hod 

pos tal At tr ibuteSet = physicalDel iveryOf f iceName, postalAddress , \ 

postalCode, postOf f iceBox, streetAddress 

localeAttr ibuteSet = local ityName , stateOrProvinceName, streetAddress 

organizat ional At tributes et = description, localeAttnbuteSet , \ 

postalAttributeSet, telecommunicationAttributeSet , \ 

searchGuide, userPassword 


oersonAttr ibuteSet = alternateName , userid, emailAddress , \ 

alternateEmai lAddress , shellAccessLanguage, subscriptions, \ 
memberships 


groupAttributeSet = description, members, activityRecord, \ 
subGroups 


# Object Classes 
top : 
alias : 


standardOb j ectClass . 0 
standardOb j ectClass . 1 


organization : standardObj ectClass . 4 

organizat ional At tr ibuteSet 

organizationalUnit: standardObjectClass . 5 : top : 

OU, FolderName , organizationalAttributeSet, \ 
groupAttributeSet 

person: standardObj ectClass . 6 

description, telephoneNumber , userPassword 


: objectClass : 

top : al iasedOb j ectName 

top : 0 : \ 

\ 


top 


organizationalPerson: standardObjectClass .7 : person : 

localeAttr ibuteSet , OU, personAttr ibuteSet , \ 

postalAttributeSet , telecommunicat ionAttr ibuteSet , title 


CN # surname : \ 

\ 



applicationEnrity : stanaardOb j ectClass . 12 : top : CN, \ 

presentationAddress: \ 

description, localityName, 0, \ 

0U f support edAppl icat ionContext 


dSA : 


standardObj ectClass . 13 : applicat ionEnt ity . 


knowledge Inf ormat ion 


# QUIPU defined object classes 


quipuDSA: quipuObj ectClass . 1 : dSA s \ 

acl, edbinfo, userPassword, manager, quipuVersion : \ 

description, lastModif iedBy , lastModif iedTime, \ 

dsaDe fault Security Pol icy , dsaPermittedSecur ityPolicy , relayDSA, \ 
listenAddress 


quipuObj ect : 

lastModif iedBy, 


quipuObj ectClass .2 : top : acl : \ 

lastModif iedTime, entrySecurityPolicy 


quipuNonLeaf Object: quipuObj ectClass . 6 : quipuObject : masterDSA : \ 

slaveDSA, t reeSt ructure , inher it edAt tribute 

quipuSecurityUser: quipuObjectClass . 7 : quipuObject : protectedPassword : 

iSODEApplicationEntity : quipuObj ectClass . 8 : applicationEntity : execVector 


externalNonLeafObj ect : quipuObj ectClass . 9 : quipuObject :: 

subordinateRef erence, crossRef erence, nssr 


# end-of-obj ect -classes 



Appendix 4 


User and Group Attribute Definitions 


# format 

# 

# name : 

# 


oid 


: syntax 


ob j ectClas s : 
ali&sedObjectName : 
knowledgelnf ormat ion : 

Name , cn : 
surname , sn : 
local ityN&me, 1 : 

stateOrProvinceName, st : 
streetAddress : 

Discipline , o : 

FolderName, ou : 
title : 

description : 

searchGuide : 

postalAddress : 

postalCode : 

postOf f iceBox: 

physicalDe 1 iveryOf f iceNarne : 

t elephoneNumber : 

telexNumber : 

f ac s imi leNumber : 

pref erredDel iveryMethod : 

pr esentat ionAddr e s s : 

support edAppl i cat ionCon text 
userPassword : 

# 

#defined for ASTROMAIL 


attributeType . 0 
attributeType . 1 

attributeType . 2 
attributeType . 3 

attributeType . 4 
attributeType . 7 
attributeType . 8 
attributeType . 9 
attributeType . 10 
attributeType . 11 
attributeType . 12 
attributeType. 13 
attributeType . 14 
attributeType . 1 6 
attributeType. 17 
attributeType . 18 
attributeType . 19 
attributeType .20 

attributeType .21 
attributeType . 23 
attributeType . 28 

attributeType .29 
attributeType .30 
attributeType. 35 


: Obj ectClass 


: DN 

: CaselgnoreString 
: CaselgnoreString 

CaselgnoreString 
CaselgnoreString 
CaselgnoreString 
CaselgnoreString 
CaselgnoreString 
CaselgnoreString 
CaselgnoreString 
CaselgnoreString 
Guide 

PostalAddress 
CaselgnoreString 
CaselgnoreString 
. CaselgnoreString 
Te 1 ephoneNumber 

: TelexNumber 

Facs imi leTel ephoneNumber 
Del iveryMethod 

Present at ionAddr ess 

OID 

Password 


ilternateName : 
she 1 1 Access Language : 
subscriptions : 
nemberships : 
members : 

act ivityRecord : 

Sroups : 
subGroups : 

f* 

userid, uid : 
emailAddress : 
manager : 

alternateEmailAddress : 
lastModif iedTime : 
lastModif iedBy : 


attributeType 
attributeType 
attributeType . 
attributeType . 
attributeType .45 

attributeType . 
attributeType . 
attributeType . 48 


36 : CaselgnoreString 

42 : CaselgnoreString 

43 : CaselgnoreString 

44 : CaselgnoreString 
: CaselgnoreString 

46 : Text : Fi le 

47 : CaselgnoreString 
: CaselgnoreString 


pilotAttributeType. 1 : CaselgnoreString 

pi lot AttributeType . 3 :CaseIgnoreIA5String 

pilot AttributeType . 10 :DN 

pilot AttributeType . 22 :Mailbox 

pilotAttributeType . 23 :UTCTime 

pilotAttributeType .24 :DN 


QUIPU defined attributes types 



treeStructure : 

accessControlList, acl : . - - _ , 

eDBinfo: quipuAttr ibuteType . 3 ‘^binfo 

masterDSA: quipuAttr ibuteType . 4 :DN 

claveDSA . quipuAttributeType . 5 -DN 

rnnt-rol- ' quipuAttr ibuteType . 15 :IA5Strmg 

• ,Vov=:ion- qu ipuAtt r ibuteType . 1 6 :IA5Stnng 

nrotectedPas sword : quipuAttr ibuteType . 17 : ProtectedPassword 

P impolicy: quipuAttr ibuteType . 18 : Security Policy 

dsaDefaultSecurityPolicy : quipuAttributeType . 19 :SecuntyPolicy 

dsaPermittedSecurityPolicy : ^^ PUA “ r ^or^InheriteSttr ibute 

inheritedAttribute, iattr: quipuAttributeType . 21 : mhentedAttribute 

execVector: quipuAttributeType 22 : Pr intableStr g 

rplavDS A- quipuAttr ibuteType. 23 :DN 

cnviordinateRef erence • quipuAttr ibuteType . 25 :AccessPomt 

cachedEDB: quipuAttr ibuteType . 29 :DN 


quipuAttributeType . 1 
quipuAttributeType . 2 


: Schema 
: Acl 


Edbinf o 

DN 

DN 

IASString 


# 

# end of attributes 



